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ABSTRACT 


This  documentation  provides  a  complete  description 
of  the  Division  War  Game  (DIVWAG)  Model  as  it  exists 
on  1  April  1976*  The  documentation  is  composed  of  an 
Executive  Summary  (Volume  I) ,  an  Analyst /Programmer 
Manual  (Volume  II),  and  the  Planner /User  Manual  (Volume 
III) .  Described  within  the  volumes  are  the  model 
design  and  development;  application;  capabilities; 
limitations;  facility,  equipment,  and  personnel 
requirements;  data  input  requirements;  mathematical 
and  logical  processes;  program  descriptions;  output 
descriptions;  user  instructions;  and  diagnostic 
messages _ This  documentation  was  originally  produced 
in  April  (1973  by  Computer  Sciences  Corporation  (CSC) 
under  Contract  DAAG  11-70-0875. 
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CHAPTER  1 


INTRODUCTION 


1.  PURPOSE.  The  purpose  of  this  volume  is  to  provide  a  summary  description 
of  the  DIVWAG  Model.  An  understanding  of  the  background  of  the  model,  some 
suggested  model  applications,  and  the  composition  of  the  DIVWAG  Model  are 
provided  by  this  volume.  The  capabilities  and  limitations  are  presented  in 
conjunction  with  the  summary  descriptions  of  all  individual  functional  ele¬ 
ments  of  the  DIVWAG  Model  and  a  statement  of  the  minimum  computer  system 
requirements. 

2.  ORGANIZATION.  Three  chapters  follow  in  this  volume.  Chapter  2  contains 
a  statement  of  the  purpose  of  the  DIVWAG  Model  and  its  suggested  applications 
followed  by  a  brief  history  of  the  model’s  development.  Chapter  3  presents 
the  model's  capabilities,  a  summary  description  of  each  functional  element  of 
the  DIVWAG  Model,  and  the  interrelationships  among  the  elements.  The  final 
chapter  specifies  the  minimum  computer  system  requirements  for  execution  of 
the  model. 


CHAPTER  2 


MODEL  PURPOSE  AND  BACKGROUND 


1.  NEED  FOR  A  DIVISION  WAR  GAME  MODEL: 

a.  Within  the  Army  Planning  System,1  there  are  two  significant  planning 
tasks  that  demand  the  use  of  a  credible  and  acceptable  division  war  game 
model:  objective  force  and  resource  planning,  and  approved  (constrained) 
force  planning.  Both  planning  tasks  contribute  to  the  primary  objectives 

of  the  Army  Planning  System;  namely,  to: 

.  Provide  timely,  pertinent  Army  views  for  consideration  by  the 
Secretary  of  Defense. 

.  Contribute  persuasively  to  the  formulation  and  presentation  of 
joint  military  strategy,  force  objectives,  and  other  matters  of 
the  Joint  Strategic  Planning  System. 

.  Provide  timely  guidance  to  Army  staffs  and  commanders. 

b.  Cost  effectiveness  studies  and  analyses  contribute  to  those  approved 
force  structures  appearing  in  the  Army  Force  Development  Plan;  and,  as  with 
objective  force  planning,  the  division  becomes  the  basic  building  block.  A 
division  war  game  model  is  of  immeasurable  value  in  arriving  at  the  design 
and  structure  of  the  Army  in  the  field. 

c.  Aside  from  direct  application  of  a  division  war  game  model  to  the 
formalized  Army  Planning  System,  there  is  a  major  requirement  to  assess  the 
value  of  competing  individual  systems  (firepower;  mobility;  command,  control, 
and  communications;  combat  service  support;  and  intelligence)  to  the  overall 
combat  effectiveness  of  Army  forces  in  the  field.  All  aspects  and  capabili- 
ties  of  these  individual  competing  systems  are  studied,  analyzed,  and  tested; 
however,  until  the  systems  are  aggregated  into  a  combat  organization  and  eval¬ 
uated  as  part  of  a  composite  system,  the  contribution  (value)  of  each  system 
to  overall  combat  effectiveness  cannot  be  properly  assessed.  The  Division  War 
Game  (DIVWAG)  model  simulates  all  functions  of  land  combat  at  an  organizational 
level  that  permits  evaluation  of  component  organizations  and  systems. 

2.  DIVISION  WAR  GAME  MODEL  DEVELOPMENT: 

a.  During  the  late  1960s  a  war  game  model,  DIVTAG  II  (Division  Through 
Army  Group),  was  developed  for  U.S.  Army  Combat  Developments  Command  (USACDC) 
and  exercised  under  the  sponsorship  of  the  USACDC  Institute  of  Combined  Arms 
and  Support  (USACDCICAS) .  DIVTAG  II  was  recognized  as  a  major  developmental 
effort  incorporating  several  potentially  significant  features,  including  the 
DIVTAG  Scenario  Language  (DSL),  which  allowed  gamers  to  formulate  their  game 
period  plans  and  orders  in  English-like  commands  for  communication  to  the 
DIVTAG  II  computer  submodels. 
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b.  Experience  in  use  of  the  DIVTAG  II  model  to  generate  game  data  for  | 
analysis  determined  that  the  DIVTAG  II  system — including  both  human  and  com¬ 
puter  elements — functioned  far  too  slowly  to  be  an  effective  tool  for  respond¬ 
ing  to  USACDC  force  analysis  requirements*  In  addition*  several  flaws  were 
suspected  in  the  application  of  DIVTAG  II  algorithms  to  the  simulation  of 
combat  reality. 

c.  On  10  August  1970,  the  Combat  Developments  Research  Office  of  Computer 
Sciences  Corporation  (CSC-CDRO)  initiated  Project  3-71,  Improvement  of  the 
ICAS  War  Game  Model  (IMPWAG)  under  Contract  DAAG11-70-C-0875.  The  overall 
tasks  of  this  project  were  to  identify  deficiencies  and  problem  areas  in  DIV¬ 
TAG  II  through  a  review  of  the  documentation;  to  establish  a  priority  list  for 
correction/resolution  of  the  deficiencies  and  problem  areas;  to  correct  or  im¬ 
prove  DIVTAG  II  within  project  constraints;  and  to  document  corrective  action, 
improvements,  and  resolutions,  as  well  as  recommended  follow-on  corrective 
action.  This  project  was  completed  on  15  May  1971. 

d.  In  February  1971,  project  tasking  was  issued  to  CSC-CDRO  to  design, 

develop,  and  validate:  ^ 

(1)  A  computer-assisted  war  game  model(s)  which  would  permit 
determination  of  the  impact  on  force  effectiveness  of  changes  in  the  mixes 
of  major  weapons  and  other  systems  at  an  appropriate  level  of  resolution. 

(2)  An  analytical  methodology  for  analyzing  the  output  of  the  model (s) 
developed  and  determining  the  effectiveness  of  a  single  force. 

(3)  An  analytical  methodology  for  comparing  alternative  forces.  t 

The  project  described  above  is  entitled  "Development  of  a  Division  War  Game 
Model  (DIVWAG)"  and  was  completed  31  December  1971. 

e.  On  15  November  1971,  CSC-CDRO  initiated  Project  2-72,  Improvement  of 
the  War  Gaming  Capability  (WAGCAP),  the  objectives  of  which  were  to: 

•  Incorporate  selected  Improvements  and  additions  into  the  DIVWAG  * 
Model 

.  Train  a  government  team  in  the  major  aspects  of  the  application 
of  the  model  to  Include  associated  analytical  methodologies. 

The  project  was  completed  on  15  July  1972. 

f.  The  DIVTAG  II  model  and  its  successor,  the  DIVWAG  model,  were  programmed' 
to  execute  on  the  Control  Data  Corporation  3300  series  computer  system  at  Fort 
Leavenworth,  Kansas.  They  contained  numerous  machine-dependent  programming 
features.  In  July  1972,  tasking  was  initiated  under  Project  1-73  to  reprogram  * 
the  DIVWAG  model  to  conform  with  newly  established  U.S.  Army  software  develop¬ 
ment  standards.  The  model  would  thus  be  readily  adaptable  to  many  computer 
systems  available  to  the  government,  and  fully  operational  on  the  Control  Data 
Corporation  6500  series  computer  system  Installed  at  Fort  Leavenworth,  Kansas, 
in  November  1972.  The  project  Included  fully  documenting  the  DIVWAG  model  and 

* 
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performing  benchmark  validation.  The  DIVWAG  documentation  set  dated  August 
1972  was  produced  as  a  result  of  Project  1-73.  The  documentation  was  sub¬ 
sequently  revised  by  CSC-CDRO  in  mid-1973.  That  revision  forms  the  basis 
for  the  current  documentation  update. 

3.  GOVERNMENT  APPLICATIONS  AND  IMPROVEMENTS.  The  War  Games  Division,  Combat 
Operations  Analysis  Directorate,  US  Army  Combined  Arms  Combat  Developments 
Activity  (CACDA)  began  operation  of  DIVWAG  in  mid-1973. 

a.  The  first  operational  game  played  with  the  DIVWAG  model  was  the 
Conceptual  Armored  Division  (CONAR)  study,  which  began  in  May  1973  and  con¬ 
cluded  in  September  1973.  With  its  completion,  a  study  was  undertaken  to 
evaluate  the  Family  of  Scatterable  Mines  (FASCAM) .  This  effort  required 
extensive  modifications  to  the  Ground  Combat  Model  as  well  as  some  modifi¬ 
cations  to  most  other  submodels.  FASCAM  was  completed  in  June  1974.  In 
October  1974,  a  short-term  Antitank  Weapon  Mix  study  was  begun,  being  com¬ 
pleted  in  January  1975.  The  Integration  of  Intelligence  from  All  Sources 
(IIFAS)  study  was  conducted  from  April  1975  to  September  1975.  Support  was 
provided  to  the  Antiarmor  Systems  Program  Review  (ASPR)  from  January  1976  to 
April  1976.  The  LEGAL  MIX  V  (Phase  I)  study  effort  began  in  April  1976  and 
continued  through  August  1976. 

b.  In  June  1974,  the  DIVWAG  Model  Maintenance  Branch  began  a  systematic 
model  improvement  effort,  specifically  designed  to:  (1)  improve  model 
efficiency;  (2)  improve  model  realism;  (3)  update  the  documentation;  and 

(4)  improve  model  input/output.  The  following  subparagraphs  describe 
generally  the  DIVWAG  model  Improvements  identified  and  accomplished  by  the 
Model  Maintenance  Branch.  These  changes  are  included,  as  appropriate,  else¬ 
where  in  the  DIVWAG  documentation. 

(1)  Efficiency.  The  task  identified  by  Model  Maintenance  as  having  the 
most  Importance  was  that  of  model  efficiency.  During  the  FASCAM  study, 
the  wall  clock  to  game  time  ratio  varied  from  5:1  to  10:1,  which  was  clearly 
unacceptable.  Several  tasks  were  Identified  to  aid  in  the  solution  of  this 
problem. 

.  Use  of  Extended  Core  Storage  (ECS) . 

.  Improvment  of  the  logic  efficiency  in  the  program  code. 

.  Use  of  common  data  areas  for  frequently  utilized  data. 

.  Barrier  location. 

.  TRANSFER/ JOIN  cleanup . 

.  Segmented  loading  versus  overlay  loading. 

(a)  Extended  Core  Storage  (ECS) .  The  use  of  ECS  became  possible  with 
the  arrival  of  the  ECS  hardware  at  the  Fort  Leavenworth  Data  Processing 
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t  Field  Office  (DPFO)  in  April  1974.  Programs  were  written  to  place  DIVWAG's 

unit  status  file  (File  1),  for  resolution  units  only,  in  ECS.  Since  ap¬ 
proximately  20  percent  of  all  data  file  accesses  were  to  File  1,  the  de¬ 
crease  in  the  wall  clock  to  game  time  ratio  was  significant:  approximately 
20  percent.  It  was  not  necessary  in  this  endeavor  to  pack  the  unit  status 
file;  that  may,  however,  become  necessary  in  the  future  as  utilization  of 
ESC  by  other  users  increases. 

(b)  Improvements  in  coding.  Selected  routines  were  examined  based  upon 
their  frequency  of  use.  The  objective  was  to  streamline  the  computer 
programming  and  thus  reduce  the  time  spent  in  these  routines.  The  Event 
Sequencing  routines,  MINUET,  and  INITIAL  were  complete  rewritten  to  accom¬ 
plish  this  objective.  In  addition,  several  routines  were  combined  with 
their  calling  routines  to  reduce  computer  time;  specifically,  CCOLF 
(countermortar/counterbattery)  was  placed  in  the  same  overlay  with  the 
Artillery  model,  and  several  small  utility  routines  were  combined  within 
the  Intelligence  model.  The  overlay  structure  of  DIVWAG  was  also  investi¬ 
gated.  Specifically,  the  Intelligence  model  was  removed  from  the  MAIN  over¬ 
lay  and  placed  in  a  separate  overlay,  and  all  overlays  were  placed  on  the 
faster  844  disk  devices.  With  the  arrival  of  SCOPE  3.4.2  at  the  DPFO, 
buffers  for  the  two  period  processor  output  tapes  became  unnecessary.  The 
space  created  in  the  MAIN  overlay  by  the  deletion  of  the  tape  buffers  and 

by  the  removal  of  the  Intelligence  model  permitted  the  creation  of  addi¬ 
tional  common  data  areas.  Reductions  in  DIVWAG  running  time  are  hindered 
by  the  large  quantities  of  data  accessed  from  an  external  disk  device. 
Reduction  in  both  the  number  of  disk  accesses  and  the  quantity  of  data 
transferred  would  decrease  wall  clock  to  game  time  ratios  significantly. 

(c)  Use  of  common  data  areas.  Upon  receipt  of  a  report  from  the 
omnibus  contractor  ( Braddock— Dunn— McDonald)  (BUM)  concerning  improving  the 
efficiency  of  CACDA’s  large  simulations.  Model  Maintenance  was  able  to 
identify  candidate  data  areas  to  be  included  in  common  blocks.  The  BDM 
report  contained  annexes  with  five  timing  runs  which  provided  numbers  of 
data  file  accesses.  By  examining  the  frequency  of  file  use  and  the  routine 
logic,  six  areas  were  determined  to  be  most  viable  candidates  for  incorpora¬ 
tion  into  common  areas.  The  amount  of  data  to  be  shifted  was  limited  by 
the  general  restriction  (self-imposed)  to  remain  below  130k8.  The  areas 
were: 


i 


.  COMEQT 
.  COMUTSR 
.  COMINCS 
.  COMZONE 
.  COMTACF 
.  COMENGR 


Equipment  categories 
Constant  data  for  UTSR  (INCS) 

INCS  data  (report  numbers,  penetration  limite) 
Battlefield  geometry  data 

Tacflre  dynamic  data  and  weapon  parameter  data 
Engineer  model 
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Both  Conaaon  One  and  Common  Two  (already  existing  commons)  were  restructured 
also  as  a  result  of  the  incorporation  of  the  new  common  areas.  With  these 
common  areas  defined  and  implemented,  and  utilizing  ECS,  timing  tests  re¬ 
vealed  a  reduction  in  input/output  (I/O)  time  of  approximately  40  percent. 
At  the  same  time,  benchmark  tests  revealed  an  overall  reduction  in  wall 
clock  to  game  time  ratio  of  nearly  50  percent.  The  ratio  experienced  was 
in  the  vicinity  of  3:1  with  one  full  division  engaged  against  two  aggressor 
divisions . 

(d)  Barrier  location.  The  task  of  locating  barriers  by  the  terrain 
cells  in  which  they  reside,  rather  than  utilizing  the  cumbersome  quadrature 
scheme  then  extant,  was  given  to  the  contractor  (BDH)  as  part  of  a  study  to 
improve  the  Engineer  submodel.  The  Study  Directive  for  this  work  was  re¬ 
ceived  by  the  contractor  on  20  August  1974. 

(e)  TRANSFER/JOIN  and  segmented  loading.  Segmented  loading  as  an  ef¬ 
ficiency  technique  and  the  improvement  of  routines  TRANSFER/JOIN  (extremely 
slow  but  infrequently  used)  were  not  attempted  due  to  time  and  resource 
constraints.  However,  TRANSFER/ JOIN  now  executes  with  less  CP  time  by  re¬ 
arranging  the  data  files  during  start  of  game  processing,  thus  reducing 
the  amount  of  data  to  be  shifted  during  TRANSFER/JOIN  execution. 

(2)  Model  Realism. 

(a)  The  second  major  area  of  improvement  was  that  of  model  realism. 

In  this  category  were  a  large  number  of  tasks,  most  of  which  had  been  iden¬ 
tified  during  the  FASCAM  game.  As  a  starting  point,  operational  and  sensi¬ 
tivity  testing  of  three  submodels  was  necessary:  Nuclear  Assessment,  Air¬ 
mobile,  and  Area  Fire.  The  Nuclear  Assessment  model  had  been  used  only 
once,  approximately  18  months  earlier;  and  the  Area  Fire  model  required 
fine-tuning  as  a  result  of  questionable  artillery  losses  incurred  during 
the  FASCAM  game. 

(b)  The  Nuclear  Assessment  model  testing  revealed  several  deficiencies. 
The  major  of  these  was  a  discrepancy  between  the  data  load  program  and  the 
model  in  relation  to  the  height  of  burst  and  damage  radius  values.  Assess¬ 
ments  were  negligible  until  the  discrepancy  was  rectified,  after  which  the 
assessment  portion  functioned  properly. 

(c)  The  Airmobile  model  test  was  conducted  in  conjunction  with  the 
gamer  training  classes.  The  only  problems  encountered  were  input  data 
discrepancies. 

(d)  The  Area  Fire  model  sensitivity  testing  revolved  about  what  ap¬ 
peared  to  be  excessively  high  losses,  especially  to  equipment  items.  It 
was  initially  discovered  that  the  gamer  input  data  for  lethal  areas,  al¬ 
though  coming  from  the  LEGAL  MIX  studies,  had  assumed  nonf ores ted  terrain. 
Since  the  same  studies  also  provided  forested  lethal  areas,  tests  were  run 
in  which  lethal  areas  ware  reduced  if  the  target  were  in  forested  terrain. 
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Resulting  losses  to  artillery  obviously  dropped.  A  second  contributing 
factor  was  again  input  data,  this  time  the  size  of  the  platoon  areas  the 
model  uses.  This  factor,  however,  had  little  Impact  on  resulting  losses 
and  was,  therefore,  not  altered.  Investigation  remains  to  be  made  on  the 
determination  of  a  lower  bound  for  the  platoon  areas  as  a  function  of  total 
unit  rectangle  size, 

(e)  A  year  earlier,  at  the  end  of  the  D1VWAG  development  contract  per¬ 
iod  in  August  1973,  Computer  Sciences  Corporation  (CSC)  produced  a  new, 
improved  mortar  routine  for  use  within  the  Ground  Combat  model.  The  mortar 
logic  then  existing  was  ineffective;  virtually  no  casualties  were  produced. 
The  new  logic  was  designed  to  portray  more  realistically  the  detection  of 
personnel  targets  and  subsequent  firing  of  mortars.  This  logic  was  not 
integrated  into  the  Ground  Combat  model  or  tested  due  to  more  pressing 
requirements  in  preparation  for  the  FASCAM  game.  The  successful  integra¬ 
tion  and  testing  was  conducted  in  June  1974. 

(3)  Documentation.  The  documentation  of  the  changes  made  for  the 
FASCAM  game  was  a  major  undertaking.  The  entire  Ground  Combat  model 
chapter  was  rewritten,  as  was  the  Air-to-Ground  model  chapter.  Portions  of 
the  Combat  Service  Support  model  documentation,  the  data  load  documentation 
(mine  load,  countermeasure  load,  end  card  standardization),  the  DSL  docu¬ 
mentation  (FASCAM  fire  and  emplace  orders) ,  and  the  battlefield  geometry 
documentation  were  rewritten.  Then  changes  in  the  documentation  associated 
with  the  model  modifications  produced  in  the  summer  of  1974  are  now 
included  in  the  documentation.  All  new  documentation  as  a  result  of  the 
summer  1974  efforts  and  subsequent  changes  is  labeled  "April  1975." 

(4)  Input/Output.  The  fourth  major  category  to  be  addressed  was  that 
of  improving  gamer  turnaround/accuracy.  Two  separate  areas  were  improved: 
data  loading  and  gamer  reports. 

(a)  DIVPREP  was  modified  to  incorporate  the  specialized  data  load 
programs  for  mine  load,  countermeasure  load,  and  area  fire  platoon  areas 
load.  In  addition,  all  end  cards  were  standardized  to  "9999,"  and  card 
images  were  printed  in  those  loads  that  previously  did  not  display  that 
information.  The  Intelligence  and  Control  model  load  was  modified  to  per¬ 
mit  reloading  the  data  during  a  game;  this  feature  was  supposed  to  be  in 
the  model  according  to  the  documentation  but  in  fact  did  not  exist.  Two 
other  tasks  were  initiated  concerning  data  input:  one  concerning  TACFIRE; 
the  other,  elevation.  At  the  suggestion  of  a  gamer,  a  scheme  was  developed 
to  simplify  the  input  for  the  TACFIRE  model.  The  scheme  was  to  associate 
weighting  factors  with  various  criteria,  such  as  target  type,  target  size, 
target  proximity.  The  simplicity  of  this  scheme  allows  the  gamer  the  flex¬ 
ibility  of  changing  the  importance  attached  to  the  various  factors  during 
a  game.  The  elevation  data  problem  consisted  of  the  inability  to  load  any 
elevation  data  other  than  that  provided  by  CSC.  The  capability  was  needed 
to  read  a  Defense  Map  Service  tape,  extract  the  desired  elevation  data, 
and  place  it  in  DIVWAG’s  elevation  data  file.  Both  tasks  were  initiated 
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but  not  completed  due  to  lack  of  personnel. 

(b)  The  improvement  of  the  gamer  postperiod  reports  was  an  attempt 

to  provide  the  gamers  with  more  informative,  consolidated  output  to  enable 
them  to  analyze  more  accurately  and  rapidly  the  results  of  one  game  period 
and  prepare  inputs  for  the  succeeding  period.  Two  tasks  directly  impacting 
on  this  effort  were  the  improvement  to  the  intelligence  report  and  the 
development  of  two  new  output  reports,  one  for  air-ground  activities,  the 
other  for  ground  combat  activities.  The  intelligence  report  was  expanded 
to  include  the  reporting  unit  of  the  sensor  detecting  the  target  and  the 
items  detected.  The  air-ground  report  consolidated  air  unit  events  and 
permitted  the  gamers  access  to  this  information,  which  previously  was  not 
available  to  them.  The  ground  combat  report  consolidated  Ground  Combat 
model  activities  by  battle,  by  attacker-defender  pair,  and  by  battle 
increment.  This  report  contained  initial  and  objective  locations,  percent 
of  the  unit  engaged,  forestation  and  roughness  indexes,  losses  to  the  eight 
weapon  systems,  and  barrier /minefield  identification  if  one  was  encountered. 

(c)  In  August  1974,  Braddock-Dunn-McDonald  Corporation,  (BDM) ,  the 
TRADDOC  Omnibus  contractor,  was  given  a  contract  to  improve  the  DIVWAG 
Engineer  and  Movement  model.  This  $65,000  project  was  completed  in 
September  1975.  Successful  integration  and  debugging  has  not  been  completed 
as  of  July  1976,  and  the  documentation  does  not  reflect  BDMfs  modifications. 
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CHAPTER  3 


SUMMARY  DESCRIPTION 


1.  MODEL  OBJECTIVE,  The  DIVWAG  Model  was  developed  as  a  computer-assisted 
war  gaining  system  for  use  in  simulating  military  interactions  between  opposing 
division-size  forces  and  their  major  elements,  with  outputs  permitting  evalua¬ 
tion  and  comparison  of  the  combat  effectiveness  of  such  division  forces.  The 
DIVWAG  Model  objective  is  to  provide  means  for  determining  the  impact  on  force 
effectiveness  of  changes  in  the  mixes  of  major  weapons  and  other  systems.  The 
DIVWAG  Model  permits  two-sided  simulations.  The  games  using  the  DIVWAG  Model 
can  be  open,  semi-open,  or  closed.  The  games  will  be  basically  rigid,  but  the 
model  can  be  operated  with  semi-rigid  intelligence  and  special  weapons  assess¬ 
ment,  Resolution  is  partially  adjustable.  Time  resolution  may  be  as  small  as 
a  hundredth  of  a  minute  (0.01  minute),  space  resolution  as  small  as  one  meter, 
and  unit  resolution  as  small  as  one  individual;  however,  for  practical  gaming 
purposes,  unit  resolution  is  on  the  order  of  a  battalion,  depending  on  terrain 
scale  and  size  forces  being  gamed. 

2.  MODEL  CAPABILITIES.  The  model  capabilities  are  discussed  in  terms  of 
operational  capabilities  and  operational  scope. 

a.  Operational  Capabilities.  The  DIVWAG  Model  has  the  following 
operational  capabilities: 

(1)  Producing  data  for  use  in  evaluating  effectiveness  of  forces 
composed  of  maneuver  units  and  their  associated  combat  support  and  combat 
service  support  units. 

(2)  Producing  data  for  use  in  the  development  of  doctrine  for  the 
employment  of  land  combat  forces. 

(3)  Producing  detailed  quantitative  data  for  use  in  comparing  the 
effectiveness  of  the  alternative  forces. 

(4)  Simulating  high  and  mid-intensity  conflict  (nuclear  and 
conventional  war). 

b.  Operational  Scope.  The  DIVWAG  Model  scope  is  defined  in  terms  of 
command  levels,  military  services,  types  of  operations,  geographical  areas  of 
operations,  rate  of  operation,  and  combat  functions. 

(1)  Command  Levels.  The  DIVWAG  Model  has  been  designed  to  produce 
data  to  evaluate  division  forces;  i.e.,  a  division  plus  an  appropriate  slice 
of  corps  or  field  army  troops.  There  is  explicit  representation  of  the  task 
organization  of  the  forces.  Echelons  of  command  are  defined,  and  reports  are 
prepared  that  reflect  the  status  of  each  command  echelon  and  include  the  aggre¬ 
gated  status  of  all  subordinate  units.  Communications  are  simulated  between 
division,  brigade/regiment,  and  battalion  command  units.  A  total  of  1000 
units  can  be  played,  divided  among  Red  and  Blue  forces.  These  units  must  be 
structured  into  task  organizations  for  each  force. 


3-1 


(2)  Military  Services.  The  DIVWAG  Model  has  been  designed  to 
accommodate  and  integrate  all  types  of  land  forces  (e.g. ,  armored,  mechanized, 
and  airmobile)  and  supporting  tactical  air  forces. 

(3)  Types  of  Operations.  The  DIVWAG  Model  provides  for  representation 
of  the  major  types  of  military  operations;  i.e.,  offensive,  defensive,  retro¬ 
grade  (delay/withdrawal),  covering  force,  and  movement.  In  addition  the  model 
is  capable  of  simulating  high  and  mid-intensity  conflict  (nuclear  and  conven¬ 
tional  war) . 

(4)  Geographical  Area  of  Operations.  The  DIVWAG  Model  can  accommodate 
rectangular  geographical  areas  as  large  as  8,000  kilometers  on  a  side.  The 
system  is  limited  in  its  application  to  worldwide  geography  only  by  availabil¬ 
ity  of  appropriate  input  data. 

(5)  Rate  of  Operation.  The  rate  of  operation  of  the  DIVWAG  war  game  is 
not  firmly  established.  It  is  estimated  that  the  simulation  model  can  produce 
game  period  turnaround  data  in  a  2:1  ratio  of  computer  time  to  combat  time  simu¬ 
lated  for  a  relatively  straightforward  combat  situation  at  a  battalion  level  of 
resolution.  Actual  timing  is  a  function  of  the  level  of  resolution  being  gamed? 
the  number  of  units  being  gamed,  the  level  of  military  activity  portrayed,  and  ' 
the  nature  of  other  computer  jobs  on  the  system  when  the  model  is  being  used  in 
a  multiprogramming  environment.  Considering  the  time  required  for  period  turn¬ 
around,  a  real  time  to  game  time  pace  of  approximately  5:1  is  considered  reason¬ 
ably  attainable  for  gaming  at  a  sufficient  level  of  complexity  to  provide  useful 
results. 

(6)  Combat  Functions.  The  DIVWAG  Model  can  address  the  following 
functions  and  evaluate  the  contribution  to  force  effectiveness  of  varying  the 
mixes  of  related  elements: 

(a)  Intelligence  functions;  surveillance  and  target  acquisition. 

(b)  Command,  control,  and  communications  functions;  decision  and 
communications  delay  times. 

(c)  Firepower  functions. 

(d)  Mobility  functions;  aerial,  ground,  and  firepower  mobility. 

(e)  Combat  service  support  functions;  supply  and  transportation; 
loss,  expenditure,  and  consumption  rates;  personnel  replacement. 

3.  FUNCTIONAL  COMPONENTS  AND  CAPABILITIES.  Functionally  the  DIVWAG  Model  is 
a  dual  system;  it  functions  physically/electronically  as  a  data  processing 
system  and,  at  the  same  time,  it  functions  in  simulation  as  a  military  combat 
system.  To  be  complete,  a  description  of  the  model  must  consider  both  aspects. 
The  DIVWAG  Model  is  described  herein  in  terms  of  its  data  processing  functional 
components  and  its  military  simulation  functional  capabilities. 

a.  Data  Processing  Functional  Components.  The  DIVWAG  software  is  divided 
functionally  into  five  processors  that  communicate  with  each  other  through 
common  files  and  records.  Designations  and  functions  of  these  processors  are 
described  below. 
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(1)  Constant  Data  Input  Processor.  The  Constant  Data  Input  Processor 
receives  data  on  cards,  edits  the  data,  and  assembles  the  data  onto  tape  and 
disk  files.  This  processor  creates  the  model  data  base. 

(2)  Orders  Input  Processor.  The  Orders  Input  Processor  receives 
player  operational  orders  in  semi-military  language  and  processes  these  orders 
into  detailed  instructions  to  the  units  simulated. 

(3)  Period  Processor.  The  Period  Processor  receives  translated 
player  orders  and  simulates  the  military  action. 

(4)  Period  Output  Processor.  The  Period  Output  Processor  receives 
results  from  the  Period  Processor  and  compiles  specific  reports  and  gross  sum¬ 
mary  reports  used  by  the  player  to  plan  subsequent  game  periods. 

(5)  Analysis  Output  Processor.  The  Analysis  Output  Processor 
receives  detailed  data  from  the  Period  Processor  as  period  history  tapes;  re¬ 
trieves,  arrays,  and  performs  the  statistical  analysis  of  the  data;  and  out¬ 
puts  the  arrayed  data  in  specified  formats. 

(6)  Data  Flow.  The  flow  of  data  between  processors  and  to  the  gaming 
staff  and  analysis  team  is  displayed  graphically  in  Figure  3-1.  The  input  and 
output  of  each  processor  are  tabulated  in  Figure  3-2. 

b.  Military  Simulation  Functional  Capabilities.  The  Period  Processor 
simulates  an  extremely  broad  and  flexible  spectrum  of  military  activity  through 
four  categories  of  models  (intelligence  and  control,  firepower,  mobility,  and 
combat  service  support).  The  models  are  described  individually  in  the  follow¬ 
ing  subparagraphs. 

(1)  Intelligence  and  Control  (INC).  This  model  provides  the 
quantitative  data  necessary  for  evaluation  of  the  contribution  of  sensor  mixes 
to  force  effectiveness.  It  integrates  the  closely  related  functions  of  sur¬ 
veillance;  target  acquisition;  combat  intelligence;  and  command,  control,  and 
communications.  Gamers  are  permitted  to  input  intelligence  from  sources  not 
simulated  by,  model  components.  The  information  obtained  from  sensors  and  from 
gamer  input  is  processed  and  used  automatically  by  the  Intelligence  and  Control 
Model  to  make  requests  for  fire  support  on  acquired  targets.  Fire  missions 
are  requested  from  available  attack  helicopters,  Air  Force  close  air  support 
(CAS),  or  ground-based  artillery  by  use  of  a  set  of  decision  rules,  according 
to  the  situation*  Sensor  information  is  also  converted  into  general  intelli¬ 
gence  by  this  model  to  produce  a  summary  report  at  the  end  of  each  game  period* 
The  summary  outlines  the  current  status  of  what  may  be  known  at  division  level 
concerning  the  size,  type,  and  location  of  the  enemy  forces  in  the  battle  area. 
This  report  is  to  aid  the  gamer  in  preparing  orders  for  the  next  game  period* 
The  Intelligence  and  Control  Model  consists  of  three  interrelated  submodels: 
Collection,  Processing,  and  Decision.  The  military  functions  simulated  by  the 
Intelligence  and  Control  Model  are  summarized  below  and  include: 

(a)  Sensing  and  Reporting.  The  capabilities  of  individual  ground 
and  aerial  sensors  are  considered  to  simulate  the  detection  and  collection  of 
information  or  Intelligence  on  units  of  the  opposing  force  and  the  summarizing 
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Figure  3-1.  DIVWAG  System  Data  Flow 


3-2.  Processor  Input  and  Output 


of  such  information  into  sensing  reports,  which  enter  the  intelligence  chain. 
Both  target  and  nontarget  intelligence  are  simulated.  Type  sensors  modeled 
include  moving  target  indicator  radar,  unattended  ground  sensor  fields,  coun¬ 
termortar  and  counterbattery  radar,  air  defense  radar,  visual  observers  in 
light  observation  helicopters  and  fixed  wing  reconnaissance  aircraft,  surveil¬ 
lance  aircraft  (Mohawk  type)  with  moving  target  indicator  radar  capability, 
and  high  performance  reconnaissance  aircraft  with  visual  and  various  photo¬ 
graphic  capabilities. 

(b)  Time  Delays  The  model  introduces  separate  delays  for  time 
consumed  in  each  of  the  principal  steps:  intelligence  collection,  intelli¬ 
gence  analysis,  routing,  and  use  of  the  information  in  decisions. 

(c)  Development  of  Targets  for  Fire  Missions.  A  separate 
channel  for  development  of  target  intelligence  is  simulated  by  the  model. 

This  channel  provides  acquired  targets  for  fire  missions  without  the  rela¬ 
tively  long  delays  involved  in  general  intelligence  processing. 

(d)  Intelligence  Analysis  and  File  Maintenance.  Comparison  of 

a  new  report  with  information  already  in  the  intelligence  files  is  simulated, 
and  if  reports  relate  to  the  same  unit  they  are  consolidated.  The  existence 
of  new  units  or  parent  units  can  be  deduced.  Intelligence  analysis  centers 
are  simulated  for  each  unit  at  maneuver  battalion,  brigade  or  regiment,  and 
division  levels.  Files  are  designed  to  stay  within  the  limits  of  10,  20, 
and  100  reports,  respectively,  for  these  three  echelons. 

(e)  Decisions  on  Informat ion /Intelligence  Flow  and  Requests  for 
Fire  Support.  The  routing  of  information  or  intelligence  among  intelligence 
analysis  centers  and  command  elements  at  the  three  echelons  is  simulated  with 
the  use  of  a  flow  structure  and  set  of  routing  criteria,  according  to  the  in¬ 
formation  in  each  report.  A  similar  set  of  criteria  is  used  to  determine 
whether  a  target  qualifies  for  fire  support  and  what  type  of  fire  support 
(attack  helicopter,  TACAIR,  ground-based  artillery)  will  be  requested. 

(f)  Contents  of  Intelligence  Report.  The  end-of-period  contents 
of  the  division  intelligence  file  are  used  for  this  report.  Each  report  that 
met  criteria  to  reach  this  file  and  was  not  discarded  from  the  file  In  favor 
of  a  more  recent  record  or  consolidated  into  a  record  of  a  parent  unit  is 
reflected  in  the  Intelligence  Report.  Items  of  estimated  information  given 
in  the  report  for  each  opposing  unit  in  this  intelligence  file  include  size, 
activity,  type,  direction  of  last  move,  time  last  senaed,  and  number  of  sen¬ 
sings  attributed  to  this  unit. 

(2)  Firepower.  The  firepower  models  provide  the  quantitative  data 
necessary  for  evaluation  of  force  effectiveness  as  a  function  of  changes  in 
mixes  and  types  of  major  weapon  systems.  The  models  integrate  all  aspects  of 
mid  or  high  intensity  combat  where  interaction  of  opposing  forces  may  occur 
and  result  in  personnel  or  materiel  losses.  The  firepower  models  coordinate 
and  integrate  the  effectiveness  of  combined  arms  teams  by  modifying  assessment 
routines  for  high  attrition  events  to  account  for  concurrent  and  parallel  kil¬ 
ling  capabilities.  For  example,  when  units  are  engaged  in  combat,  kills  are 


related  to  the  number  of  fire  elements  on  opposing  sides.  Should  an  attack 
helicopter  fire  team  make  an  attack  during  a  ground  combat  cycle,  the  ground 
combat  cycle  will  be  interrupted  immediately  prior  to  the  helicopter  attack, 
the  status  of  the  units  in  ground  combat  will  be  updated  to  that  moment,  the 
effects  of  the  helicopter  attack  on  the  current  ground  combat  unit’s  status 
will  be  assessed,  and  the  ground  combat  cycle  will  be  resumed.  The  same 
assessment  technique  is  followed  for  other  interfacing  firepower  activities. 
Five  models  simulate  the  firepower  function:  Ground  Combat,  Area  Fire, 

TACFIRE,  Nuclear  Assessment,  and  Air  Ground  Engagement.  Each  of  these  models 
assesses  damage  inflicted  and  produces  loss,  expenditure  rate,  and  consumption 
data  for  use  in  evaluating  the  supply  and  transportation  systems. 

(a)  Ground  Combat  Model: 

1..  The  Ground  Combat  Model  represents  the  interaction  between 
the  direct  fire  weapons  of  opposing  maneuver  units  engaged  in  ground  combat. 

2 .  The  model  represents  the  interaction  and  the  effects  of 
weapons  of  cross-reinforced  units.  Combat  power  may  be  enhanced  by  employing 
combined-arm  forces  against  the  enemy.  The  effectiveness  of  the  maneuver  unit 
is  largely  dependent  on  the  combination  and  coordination  of  weapon  systems 
within  the  unit.  The  distance  of  separation  of  weapon  systems  is  limited  so 
that  mutual  support  is  possible  when  weapon  density  permits. 

3^.  The  impact  of  the  environment  is  represented  by  the  model. 
All  movement  in  ground  combat  is  subject  to  the  constraints  imposed  by  the 
environment  wherein  ability  to  move  forces  by  ground  is  degraded  by  the  effects 
of  adverse  weather,  terrain,  and  visibility.  The  application  of  firepower  is 
largely  controlled  by  the  environment  since  effectiveness  of  each  weapon  sys¬ 
tem  is  limited  by  its  associated  target  acquisition  capabilities.  Target 
acquisition  cannot  occur  unless  line  of  sight  exists  between  the  observer  and 
target.  Line  of  sight  may  be  severely  limited  due  to  terrain  roughness,  vege¬ 
tation,  and  forestation.  A  firer  may  lose  line  of  sight  on  a  moving  target 
before  firing  a  round.  A  moving  target  may  drop  out  of  line  of  sight  during 
the  time  of  flight  of  the  round.  Target  acquisition  is  limited  by  visibility, 
whether  due  to  adverse  weather  or  night  combat  operations*  Under  conditions 
of  reduced  visibility,  target  acquisition  is  enhanced  by  the  employment  of 
night  vis’ion  equipment. 

4^  The  interaction  of  each  maneuver  unit  with  the  enemy  is 
considered  by  the  model  in  terms  of  a  maneuver  unit’s  effectiveness  and  vul¬ 
nerability.  The  maneuver  unit’s  effectiveness  is  Influenced  by  the  level  of 
activity.  As  the  level  of  activity  Increases,  more  weapon  systems  can  acquire 
targets.  As  individual  moving  weapon  systems  stop  to  fire,  the  signature 
(i.e. ,  evidence  of  that  weapon  firing)  Increases  with  the  level  of  activity. 

The  maneuver  unit’s  vulnerability  is  influenced  by  the  level  of  activity.  A 
firing  weapon  system  may  disclose  its  position  and  become  a  target  for  enemy 
fire. 


J>.  The  Ground  Combat  Model  relies  heavily  on  the  existence 
of  data  to  describe  weapon/ amnunlt ion  effectiveness  against  varying  target 
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types  in  a  combat  situation.  The  model  also  requires  adequate  data  to  des¬ 
cribe  the  target  acquisition  capabilities  of  all  employed  sensor  types  other 
than  unaided  vision. 

(b)  Area  Fire  and  TACFIRE  Models.  The  Area  Fire  and  TACFIRE 
Models  simulate  the  scheduling  of  nonnuclear  munitions  for  area  fires,  and 
the  delivery  and  assessment  of  results  of  nonnuclear  fires.  Area  fire  events 
are  generated  by  two  methods.  First,  gamers  issue  fire  orders  prior  to  the 
engagement  period  for  fire  with  specific  ammunition  at  apseciflc  coordinates. 
Second,  during  the  engagement  period  target  information  is  developed  by  the 
Intelligence  and  Control  Model  with  a  request  for  nonnuclear  artillery  fire, 
and  the  TACFIRE  Model  automatically  schedules  the  required  fire  missions  for 
the  fire  units.  The  automatic  mode  is  referred  to  as  the  TACFIRE  mode. 
Targets  in  this  mode  consist  of  targets  of  opportunity  and  are  limited  to 
those  enemy  units  detected  and  processed  by  the  Intelligence  and  Control 
Model.  Fire  units  are  battalion  or  battery  sise,  and  Integral  fire  units 
are  used  in  attacking  area  fire  targets.  The  fire  units  are  constrained  by 
range  limitations,  volley  firing  times,  number  of  tubes  or  rails  per  fire 
unit,  and  weapons /munitions  availability.  A  target  threat  priority  value 
ranging  from  1  to  9  is  assigned  to  each  area  fire  target,  and  is  based  upon 
its  estimated  size,  type,  activity,  range,  and  the  tactical  doctrine  used  in 
artillery  employment  for  the  particular  game.  Priority  one  is  a  higher 
priority  than  priority  two,  etc.  If  a  backlog  of  targets  exists,  targets 

are  engaged  in  highest  priority  order.  The  Area  Fire  and  TACFIRE  routines 
are  separated  into  three  functional  classes:  scheduling,  delivery,  and 
assessment.  Most  of  the  routines  for  the  automatic  TACFIRE  mode  *re  con¬ 
cerned  with  scheduling  of  fires.  The  delivery  routines  deliver  th^  muni¬ 
tions  on  target  and  determine  units  whose  presence  in  the  Impact  area  will 
require  assessments.  The  assessment  routines  then  calculate  the  effects  of 
the  fire  events,  based  on  number  of  rounds  fired,  lethal  area  of  nonnuclear 
munitions,  dimensions  of  the  target,  number  and  density  of  target  elements, 
and  target  vulnerability.  The  assessment  routine  makes  adjustments  in 
target  personnel  and  equipment  to  reflect  losses  and  in  the  fire  unit's  muni¬ 
tions  on  hand  to  reflect  expenditures. 

(c)  Air  Ground  Engagement  Model.  The  Air  Ground  Engagement 
Model  simulates  for  both  opposing  forces  all  air-to-ground  and  ground-to-air 
interactions  falling  within  the  definition  of  close  air  support  (CAS)  and 
otherwise  directly  related  to  ground  combat  operations.  These  operations  in¬ 
clude  aircraft  fires  provided  by  other  Services,  and  Army  aircraft  delivering 
direct  aerial  fires  (DAF) .  The  Air  Ground  Engagement  Model  determines  all 
attrition  and  casualty  results  of  such  interactions.  The  Air  Ground  Engage¬ 
ment  Model  is  sufficiently  flexible  that  major  changes  in  aircraft  charac¬ 
teristics,  quantity  or  mixes  of  the  major  weapon  systems,  or  their  modes  of 
employment  will  be  reflected  in  the  measures  of  force  effectiveness.  Single 
or  multiple  aircraft  flights  are  generated  by  the  Intelligence  and  Control 
Model  or  are  directed  by  gamer  orders.  Attrition  of  aircraft  while  in 
flight  is  based  on  the  location  of  air  defense  capable  units;  l.e.  units 
that  contain  air  defense  weapons.  The  Air  Ground  Engagement  Model  divides 
the  flight  path  into  the  following  segments  as  appropriate:  airbase  to 

safe  point,  safe  point  to  target,  target  to  safe  point,  and  safe  point  to 
air  base. 


\ 
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.  Selects  from  available  aircraft  and  munitions  types  those 
best  suited  for  the  mission,  determines  the  time  required 
for  aircraft  preparation  and  pilot  briefing,  and  schedules 
the  time  for  aircraft  to  be  airborne. 

.  Maintains  a  current  status  record  for  aircraft  assigned  to 
a  mission,  to  include  munitions  and  fuel,  aircraft  losses 
caused  by  enemy  activity,  and  effects  of  the  aircraft  on 
enemy  targets. 

.  Moves  the  aircraft  progressively  along  the  mission  segments, 
assessing  aircraft  status, ^  attrition,  and  accomplishments 
at  the  completion  of  each  segment  to  determine  if  the  mis¬ 
sion  should  continue. 

.  Determines  the  results  of  attacks  on  targets  in  terms  of 
aircraft  losses  and  target  losses. 

.  Upon  completion  of  the  mission  and  return  to  the  airbase, 
aggregates  total  mission  results  (including  total  mission 
time),  assesses  aircraft  damage,  and  determines  delay  times 
for  subsequent  mission  availability  of  the  aircraft. 

(d)  Suppression  Model.  The  treatment  of  suppressive  effects  of 
area  fires  or  aerial  strikes  upon  a  unit  was  introduced  to  the  DIVWAG  Model 
through  the  addition  of  a  Suppression  Model.  This  model  represents  suppres¬ 
sive  effects  by  the  interruption  of  selected  activities  (unit  movement,  deliv¬ 
ery  of  area  fires,  delivery  of  air  defense  fires)  in  response  to  incoming  fire. 
Length  of  interruption  depends  on  the  activity  interrupted  and  nature  of  fire 
received,  and  the  interruption  is  extended  as  fires  continue  to  be  received. 

(e)  Nuclear  Assessment  Model.  The  Nuclear  Assessment  Model  simu¬ 
lates  the  delivery  of  and  the  assessment  of  results  of  tactical  nuclear  fires. 
All  nuclear  fires  are  conducted  in  response  to  gamer  fire  order,  issued  prior 
to  the  simulated  engagement  period.  The  gamer  fire  order  specifies  the  unit 

to  fire,  weapon  and  munition  to  fire,  yield,  height  of  burst  (if  controllable), 
and  designated  ground  zero.  Thus,  all  planning  of  nuclear  fires  must  be  car¬ 
ried  out  by  the  gamer  prior  to  an  engagement  period.  In  response  to  a  nuclear 
fire  order,  the  Nuclear  Assessment  Model  simulates  the  actual  firing,  the 
nuclear  detonation,  and  the  assessment  of  effects  against  all  units  as  well 
as  on  obstacles  and  facilities  within  the  effects  area  of  the  round.  The 
detonation  and  effects  of  atomic  demolition  munitions  (ADM)  are  also  simulated 
by  the  model.  Simulated  effects  include  those  due  to  blast,  prompt  nuclear 
and  thermal  radiation,  and  delayed  effects  due  to  induced  radiation.  Fallout 
effects  are  not  simulated. 


1. 


Includes  effects  of  air  defense  activities,  weather,  and  terrain. 


(3)  Movement  Model .  The  Movement  Model  represents  unit  movement 
other  than  airmobile  operations  including  the  effects  of  those  activities 
that  serve  to  improve  or  impede  movement.  The  Movement  Model  provides  the 
quantitative  data  necessary  for  evaluation  of  force  effectiveness  as  a  func¬ 
tion  of  ground  movements,  and  the  related  effects  of  significant  changes  in 
the  mixes  and  types  of  mobility  means.  The  Movement  Model  considers  the 
following  aspects  of  force  mobility: 

(a)  Air  Movement.  The  Air  Movement  section  of  the  model  simu¬ 
lates  moves  by  aircraft  not  in  connection  with  airmobile  operations.  Air 
movements  may  be  ordered  externally  by  gamers  or  generated  internally  by  the 
Air  Ground  Engagement  Model.  Aircraft  availability,  class  II1A  supplies,  and 
weather  limitations  are  checked  before  the  air  movement  is  allowed.  Air  routes, 
altitudes,  and  speeds  are  specified  by  the  gamer  order  or  are  determined  by  the 
model  generating  the  movement  internally.  Once  tha  air  movement  is  initiated, 
it  will  be  completed  unless  terminated  due  to  losses.  At  the  end  of  each  flight 
segment  the  unit  will  be  updated  to  reflect  losses  of  aircraft  and  personnel 
and  the  status  of  associated  supplies. 

(b)  Ground  Movement.  The  Ground  Movement  section  of  the  model 
simulates  moves  by  surface  transportation.  Ground  movements  of  units  not 
engaged  in  combat  are  ordered  by  gamers.  Ground  movements  are  affected  by 
category  of  move,  unit  mission,  formation  type,  vehicle  mobility  characteris¬ 
tics,  terrain  conditions,  daylight  or  darkness,  road  nets,  weather,  natural 
obstacles,  and  enemy  created  conditions.  The  maximum  movement  rate  for  a 
unit  is  the  rate  of  the  slowest  type  vehicle  in  the  unit.  Some  of  the  other 
characteristics  of  ground  movement  are  indicated  below. 

1^.  Administrative/Supply  Movements.  Administrative  routes 
are  generated  by  gamer  orders;  supply  routes,  by  the  Combat  Service  Support 
Model.  The  road  movement  rate  depends  on  road  type,  grade,  weather  conditions, 
and  nighttime  or  daytime  conditions.  Administrative  movements  are  executed  in 
segments  determined  by  terrain  cell  boundaries  or  en  route  obstacles.  Units  ' 
are  halted  by  events  scheduled  for  the  moving  unit  and  by  encountering  obsta¬ 
cles.  After  the  delay,  the  unit  is  not  able  to  make  up  this  lost  time  but 
continues  to  move  at  its  appropriate  rate. 

2^  Tactical  Movements.  Tactical  routes  are  generated  by 
gamer  orders  and  are  executed  in  segments  in  the  same  manner  as  administrative 
movements.  Starting  times  and  normal  tactical  movement  rates  are  specified 
for  each  unit  type  for  attack,  withdrawal,  and  reinforcing  missions,  as  well 
as  for  day  or  night  movements.  Units  are  halted  for  obstacles  or  minefields. 
After  such  delay,  tactical  units  attempt  to  make  up  the  lost  time,  and  move 
at  the  limiting  mobility  class  rate  for  that  purpose.  The  limiting  mobility 
class  rate  depends  on  terrain  roughness  and  vegetation,  slope  and  soil  traffic- 
ability,  forestation,  weather  conditions,  and  nighttime  or  daytime  conditions. 
Each  equipment  type  is  assigned  to  a  mobility  class,  and  only  those  mobility 
classes  used  during  tactical  movements  are  considered  for  determining  the 
limiting  mobility  class. 


Maneuver  Movements.  Maneuvering  weapon  systems  execute 
their  movements  at  maximum  limiting  mobility  class  rates.  Since  different 
weapon  systems  have  different  maximum  rates,  and  since  the  movement  rate  of 
a  maneuvering  unit  is  limited  by  the  rate  of  the  slowest  weapon  system,  faster 
weapon  systems  have  periods  of  time  when  they  are  stationary.  Maneuver  move¬ 
ment  is  controlled  entirely  by  the  Ground  Combat  Model,  which  determines 
detection  capabilities,  vulnerability,  and  weapon  system  capabilities. 

(c)  Stay  Activity.  The  model  also  simulates  stationary  activities 
for  all  gamed  units  not  engaged  in  other  specified  activities;  i.e.,  all  units 
that  are  not  performing  another  military  activity  such  as  firing,  moving,  or 
combat.  Whether  or  not  addressed  by  gamer  orders,  an  inactive  gamed  unit  will 
consume  classes  I  and  III  supplies  and  can  be  assessed  as  to  losses  and  status; 
other  units  can  gain  information  about  the  inactive  unit.  If  a  unit  has  com¬ 
pleted  all  its  orders  before  the  end  of  a  game  period,  the  unit  will  automati¬ 
cally  stay  until  the  end  of  the  period.  Stay  activity  orders  can  be  written 

to  command  ground  units  to  remain  in  position  for  a  specified  length  of  time 
or  until  a  specified  game  time  arrives. 

(d)  Engineer.  The  Engineer  Model  simulates  the  scheduling  and 
execution  of  engineer  activities  associated  with  the  construction  and  destruc¬ 
tion  of  obstacles  and  facilities.  The  model  accepts  engineer  tasks,  assigns 
task  priorities,  determines  task  feasibility,  mobilizes  mission  units  to 
execute  the  tasks,  simulates  the  engineering  activity  in  terms  of  time  and 
materiel  resources  used,  and  demobilizes  the  mission  units. 

1,.  Obstacles  and  facilities  are  parts  of  an  overall  barrier 
plan  developed  for  the  game  being  conducted.  Engineering  activities  can  be 
initiated  by  gamer  order  to  start  work  on  a  specified  obstacle  or  facility  or 
by  request  from  the  Movement  Model  when  some  engineering  activity  is  necessary 
for  the  conduct  of  a  directed  movement.  Where  the  engineer  activity  is  re¬ 
quested  by  the  Movement  Model,  the  moving  unit  is  unable  to  complete  its  move 
until  the  engineer  activity  is  completed. 

2*  Engineer  task  priorities  are  based  primarily  upon  the 
urgency  of  the  activity  in  terms  of  its  impact  on  the  force’s  overall  plan 
of  maneuver.  Task  feasibility  is  determined  in  terms  of  task  site  (proximity 
to  FEBA)  and  time  and  materiel  availability. 

3.  The  Engineer  Model  automatically  allocates  resources  to 
each  feasible  task,  constructs  a  mission  unit  to  execute  the  task,  moves  the 
mission  unit  to  the  task  site,  simulates  the  initiation  of  work  when  suffi¬ 
cient  resources  are  on  site,  periodically  updates  task  status  until  completion 
of  the  task  (or  until  a  gamer  order  to  stop  the  task  is  encountered) ,  and  re¬ 
turns  the  mission  unit  to  its  origin. 

(4)  Airmobile  Model.  The  Airmobile  Model  permits  simulation  of  a 
variety  of  airmobile  operations.  To  maintain  a  high  degree  of  flexibility 
in  application  of  the  model,  the  simulation  depends  upon  the  gaming  staff 
for  most  of  the  general  planning  and  decision  making  prior  to  execution  of 
an  airmobile  operation.  These  plans  are  relayed  to  the  model  by  a  set  of 
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DSL  orders.  Activities  actually  simulated  within  the  model  include  allocation' 
of  transport  and  escort  aircraft  to  conduct  the  operation,  staging  and  loading 
of  the  airmobile  force,  the  actual  airmobile  movement,  attrition  of  the  air¬ 
mobile  column  while  in  flight  to  and  from  the  objective  area,  suppression  of 
air  defenses  by  escort  aircraft,  deplaning  at  a  landing  zone,  refueling  and 
rearming  of  aircraft,  and  the  release  of  aircraft  from  operational  control 
of  the  airmobile  force. 

(5)  Combat  Service  Support  Model.  This  model  simulates  the  resupply 
of  manpower  and  materiel  to  units  within  the  DIVWAG  system.  The  model  deals 
with  personnel  replacements,  replacement  of  major  items  of  equipment,  and 
resupply  of  critical  consumables  such  as  food  (class  I),  fuel  (class  III  and 
IIIA),  barrier  materials  (class  IV),  and  ammunition  (class  V). 

(a)  Replacement  of  personnel  and  major  items  is  accomplished  once 
for  each  simulated  day  of  combat.  Availability  of  replacement  personnel  and 
major  end  items  is  on  a  daily  basis,  input  by  the  gamer,  with  available  assets 
accumulating  over  time;  i.e.,  assets  not  used  on  previous  days  are  available 
in  addition  to  those  available  for  the  current  time.  Requirements  are  based  t 
on  unit  losses,  represented  by  the  authorized  unit  level  of  personnel  and 
major  items  less  the  quantities  on  hand  within  the  unit  at  the  time  of  the 
replacement  action.  First  priority  for  replacements  and  major  end  items  is 
to  front  line  maneuver  units,  second  priority  to  reserve  maneuver  battalions 
and  all  artillery  units,  and  third  priority  to  all  other  units.  If  sufficient 
replacements  or  major  end  items  are  not  available  to  fill  the  needs  within  a 
unit  priority  group,  each  unit  receives  a  pro  rata  share  of  available  resources 
based  on  amounts  required  by  all  units  within  the  priority  group.  Replacement; 
and  major  end  items  arrive  at  the  receiving  units  after  an  appropriate  travel  ' 
delay. 


(b)  The  treatment  of  resupply  of  consumables  within  the  Combat 
Service  Support  Model  is  conceptually  similar  to  treatment  of  replacement  of 
personnel  and  major  items.  Implementation  differs  to  account  for  the  following: 

1^.  No  limitation  is  placed  on  quantities  of  consumables 
available  to  the  force.  In  the  case  of  consumables,  the  primary  limiting 
factor  is  the  availability  of  transportation  to  move  the  materiel  from  vari¬ 
ous  supply  points  to  the  consumer.  The  model  treats  movement  of  consumables 
through  a  series  of  supply  points  from  the  nominal  point  of  entry  into  the 
force  to  the  using  unit.  The  model  uses  either  a  unit  distribution  or  a  sup¬ 
ply  point  distribution  method  on  each  leg  of  the  supply  chain,  depending  upon 
the  supply  class  of  the  consumable  and  the  nature  of  the  receiving  unit  at 
each  node. 


_2.  To  accomplish  a  more  continual  flow  of  consumables, 
resupply  requirements  are  determined  and  actions  initiated  on  a  more  frequent 
basis  than  with  replacements.  The  model  currently  uses  a  2-hour  cycle  for 
all  consumables  except  class  I,  which  is  on  a  once-a-day  cycle.  (As  experi¬ 
ence  is  gained  with  the  model,  some  appropriate  cycle  between  the  extremes 
of  hourly  and  daily  requirement  determination  should  be  established.) 
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3^  A  request  for  resupply  of  consumables  is  generated  if 
the  quantity  in  the  unit  trains  is  less  than  a  fixed  percentage  of  the 
authorized  amount  in  trains.  That  percentage  is  currently  set  at  fifty 
percent. 

4.  PROGRAM  SIZE.  The  DIVWAG  model  programs  ,  including  the  five  processors 
and  associated  utility  programs,  consist  of  96,900  FORTRAN  source  cards. 
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CHAPTER  4 


COMPUTER  SYSTEM  REQUIREMENTS 


The  minimum  computer  system  requirements  for  execution  of  the  DIVWAG 
model  are  listed  below. 


Core  storage  capacity 
Magnetic  tape  drives 
Magnetic  disk  capacity 
Printer 
Card  reader 
Software  features 


124,000  words  (octal) 

2 

3,000,000  words  (decimal) 
1 
1 

FORTRAN  compiler  (ANSI)1 
Overlay  loader  (2  levels) 
Mass  storage  input/output 


1.  American  National  Standards  Institute  Incorporated,  American  National 
Standard  FORTRAN.  ANSI  X  3.9;  1966. 
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